Updated rendering kernel to rtrace 8.4.2 (hence the version number). This is the most significant change, and affects much. On the positive side, version 8.4.2 is much faster than version 7 (on which MacRTrace version 1.0 was based), and has several new features. On the negative side, version 8.4.2 is an incredible memory hog compared to version 7. It is no longer possible to render very large images on machines with limited memory; for instance, the default image size, 256x256, requires almost 2 Meg of memory to render, just for the ray-tracing kernel. For those who care, the main reason for this increase is that version 8.4.2 keeps the entire bitmap in memory, as floating point RGB triples. That is, each pixel takes a remarkable 24 bytes. This really adds up. 1024 x 1024 images, which I used to render all the time with version 1.0, require more than 25 Meg now. Note that this is fairly easily attainable with virtual memory, and since ray tracing lends itself well to virtual memory, the slowdown isn’t that bad. Still, this is annoying. I don’t see any way to avoid RTrace’s new memory-hogginess, except perhaps to use a smaller floating point representation, or even an integer representation for RTrace’s internal bitmap. This is Antonio’s call, though, not mine, and he might well object to the slowdown that would introduce. As it is, it looks like RTrace has entered a new era, and now requires a pretty powerful system to do worthwhile work. For those who just can’t handle this, note that MacRTrace 1.0 is still a pretty impressive ray tracer, and can run on a 68000 with 1 Meg.
  MacRTrace now requires a math coprocessor, System 7, and a 68020 or better processor. This is in keeping with the “new era” mentioned in the previous paragraph; the memory requirements are so large now that, chances are, anyone who has enough memory to run MacRTrace also has these other powerful features. If you don’t have a math coprocessor, and still want to run MacRTrace, you can request a special version which does not require an FPU by sending mail to Greg Ferrar (ferrar@uxa.cso.uiuc.edu).
  The scene is now read “asynchronously,” in the sense that users can do other things with MacRTrace while a long scene is being read. Most importantly, users can set the rendering options, which is sometimes time-consuming, in parallel with the scene read.
  MacRTrace now always keeps the image in memory. This uses some memory, but since it uses only 4 bytes per pixel compared to the 24 bytes per pixel that the kernel uses already, the extra memory use should not be significant. Keeping the image in memory has all sorts of advantages. For instance, use of PPM files have been eliminated, and the image is never written to disk unless the user saves it.
  Animations are now saved to the disk as they are created, rather than saving them as intermediate PPM files, and converting later. This saves disk space and is more natural. However, you now have to save every time you render an animation. This is nothing new, really; it’s just explicit now and it happened behind the scenes before.
  The user interface has been subtly changed in dozens of places. Most of these are just obvious improvements and need no explanation. The Render button acts quite differently now (some might say strangely); if you get confused, look it up in The Options Dialog or using balloon help.
  As you may have noticed by now, the documentation is no longer in Microsoft Word format. It is a stand-alone document, created by the great Shareware program DOCMaker. (As in version 1.0, much of the documentation is duplicated in Balloon Help).
  MacRTrace can now read a subset of the .scn format. Specifically, it can read any .scn file which does not contain proprocessing directives. Unfortunately, many .scn files do contain preprocessing directives; these can be read either by converting them to .sff using scn2sff for unix and other systems, or by using a Macintosh-based C preprocessor, like the ones included with MPW, Symantec C++, and CodeWarrior, to preprocess the .scn file. These limitations make the .scn support less useful than it might have been, but my purpose in supporting .scn was not to fully support .scn, but rather to support a format which is easy to generate by hand. Those who have attempted to create scenes using .sff will appreciate the ease of use of the .scn format.
  MacRTrace now runs native on PowerMac computers. More specifically, the MacRTrace application is a fat binary, which runs native regardless of the type of Mac it’s running on. This results in truly phenomenal speed increases; I still can't believe my eyes when I watch it run on a PowerMac. My thanks to Rob Hagopian and Paul Snively for their work on the PowerMac port.